未来，没有对象，就别想过好日子！

对象，是对象存储的昵称。相对于NAS，我喜欢叫她OBJ，一个基于网络的存储程序。

最早由AWS（Amazon Web Services）的工程师开发了这个后来被称为（Simple Storage Service）的程序，因为三个首字母都是S，所以简称S3。目前，Amazon S3已经成为了事实上的对象存储标准，而这也是一个在线零售商向科技公司转型的印记。

按照贝索斯的理解，作为一个网络服务，对象可以存储和检索任意位置，任意数量的数据，当时贝索斯对S3提出要求是，“其规模要达到无限大，而且没有计划性的停机时间。”

对象的使用场景和分类

商业环境中，很多公司都有大量的电子影像和文件需要存储，例如，银行票据，电子保单和电子合同等。当然更少不了各种手机APP产生的照片、音乐和视频。这些场景以前都是NAS，未来终将归于对象。

从某种程度上讲，在非结构化的存储世界里，对象存储一切，下面就介绍几个对象给你认识。

商用：主要是HDS的HCP、IBM的CleverSafe和NetApp的Grid等 

开源：事实上似乎只有Ceph

搞对象的经验和教训

有人的地方就有江湖，有产品地方，除了故事，还有事故。还记得上次NAS文章中提到的那个朋友吗？今天接着讲他跟HDS的小故事。

朋友说，多年前他们公司就建了影像集中存储平台，数据存在NAS上，但是随着业务快速发展，影像文件飞速增加，NAS在存储容量和inode等方面都受到了挑战。也就是说，随着影像文件越来越多，这个痛点越发明显。当然，总是有办法可以维持，但是能维持多久？

长痛不如短痛，为了应对未来更大规模的存储需求，上马对象成了一项必须完成的任务。看Gartner分析报告，跟行业用户技术交流，最终，他们选择了HCP，作为影像平台的新一代存储解决方案。

但是上线没多久，对象存储就遇到了性能不稳的情况，这次不再是245万个垃圾文件，而是8000万个生产影像。

问题很快就定位了，厂商给出的结论是，他家的桶（Bucket，对象存储里的专有名词，用来放具体对象数据）需要文件存储时有相应的目录层次，否则就会造成数据分布不均衡，影响性能。最后，在开发人员的配合下，重新对数据做了迁移，算是彻底消除了这个隐患。

对于非结构化数据的管理，不管使用什么存储，NAS还是OBJ，也不管产品什么样，最安全，最稳妥的方式就是一定要设计好数据存储的目录层次。

你以为故事就这样结束了？当然没有，这只不过是头盘，后面还有主菜，因为篇幅有限，找机会再讲后来发生的故事。

对象的现状与对比分析

对象存储的主要特征，基于S3标准的X86分布式，采用多副本和纠删码存储数据。不过，在本周的华为2019上海全联接大会上，已经有人开始玩ARM了。

目前，传统商业存储厂商都有自己相应的对象存储产品，各家也都有拿的出手的客户案例，而我这次主要想谈谈开源的Ceph。

如果让我给Ceph定位，我就把Ceph跟OBJ划等号。当然无论做云的，还是做存储的都不会认同我的说法，因为他们比我更能跟客户讲故事。

早年间，我朋友就开始接触学习Ceph，做了很多准备工作，但因为某些原因，最后并没有真正落地到具体项目。最近听说他那里又有新需求，打算重新对开源对象存储进行测试，就顺便问了问情况。

目前基于Ceph研发的存储玩家主要是XSKY和杉岩数据，也是他们这次测试的主要目标。

XSKY，不多说了，算是Ceph的布道者。

杉岩数据，一家总部在深圳，专注存储的科技公司，业务发展还不错。朋友说他印象最深的就是，第一次跟杉岩做交流，看了几页PPT，就已经知道杉岩是干嘛的了，完全对标XSKY，商业战略和产品定位很清晰。当然，杉岩的对象产品也提供CDP这种数据保护，算是自己独特的优势。

要说产品功能和售后服务，相对还是传统存储厂商更完善。初创公司都是基于开源Ceph做的研发，版本迭代快，产品功能同质化，我觉得技术差异反而弱化，需要综合评估服务，当然姿态也很重要。

写在对象之后

客户搞开源对象似乎就两种选择，要么自己养一票懂代码人的玩自研，要么就找个专业基于Ceph做研发的公司买产品，前者门槛太高，国内玩得起的没多少，后者似乎像是更现实的做法。

朋友负责的对象存储，上线两年，对象存了5亿多，目前每天增量还有100万左右，这个量级，没个对象，谁受得了。

这个时代，面对新技术、新产品，唯一的选择就是以开放的心态去拥抱他。没对象的，抓紧找个合适的吧。否则，被时代抛弃的时候，连声再见都没有。